Background
Large-scale deployment of mass media services/media objects over wireless communication networks may utilize broadcast/multicast network capabilities. Multimedia Broadcast and Multicast Service (MBMS) and Broadcast and Multicast Service (BCMCS), as proposed by telecommunications specifications-setting projects, such as the 3rd. Generation Partnership Project (3GPP) and 3rd. Generation Partnership Project 2. (3GPP2), as well as, MediaFLO™ technology as developed and available from Qualcomm Incorporated of San Diego, Calif., are targeted towards enabling multimedia content transfer to handheld communication devices over the wireless channel. The MediaFLO™ broadcast network provides services that allow transfer of media objects, such as digital movie clips, sports broadcasts, video clips and music files. Additionally, other broadcast technologies have been implemented globally, for example, Digital Video Broadcasting-Handheld (DVB-H) has gained acceptance in Europe, Integrated Services Digital Broadcast-Terrestrial (I-SDB-T) has been standardized in Japan, and Digital Multimedia Broadcasting (DMB) has been adopted in China.
FIG. 1 provides for a block diagram illustrating the services 10 provided in a broadcast network particularly suited for wireless delivery, such as MediaFLO™ or the like, in accordance with the prior art. The service may include real time services 20, such as news, sporting events or the like, non-real time services 30, such as pre-recorded programming and the like, and IP datacast services 40, such as news, weather, stock quotes, and the like. In addition to real time services 20, non-real time service 30 and IP datacast services 40 the broadcast network provides for a common overhead service 50 for broadcasting overhead information. Unlike real time services 20, non-real time service 30 and IP datacast services 40, the common overhead service 50 does not carry any media content. Instead, the common overhead service is responsible for broadcasting overhead information that is essential for a device to properly receive the other services. For example, the overhead information provides for informing the media content-receiving devices of system events, state, status and system information and to assist the devices in accessing the other services. In this regard, the overhead service 50 includes a primary flow/channel 52, a notification flow/channel 54, a plurality of system information flows/channels 56 and a configuration flow 58.
The system information flows 56 may include a marketplace for offering the device user service subscription options, such as games, movies, programs and the like, a Media Presentation Guide (MPG), service information and the like. In general, the system information flows 56 assist device users in subscribing to services and viewing content. The configuration flow 58 broadcasts necessary configuration messages that include configuration settings used by the devices to receive the media content delivered by the other services. The notification flow 54 may include various types of notification messages, such as service alerts, client application upgrades and the like. The primary flow 52, which the device listens for on a frequent basis, such as every five minutes or the like, indicates whether the notification, system information and/or configuration information broadcasted by their respective flows have been updated. If the primary flow indicates an update, the device tunes to the respective individual flow channel associated with the update and updates the associated overhead information.
In current broadcast networks, the primary message delivered via the primary flow 52 includes two fields related to the notification flow. The first field is a notification version identifier that indicates the current version of the notification. If a device's local notification version differs from the notification version in the primary flow message, the device needs to tune to the notification channel and listen to the notification flow. The second field is the number of notifications field that indicates the number of notifications associated with the current notification version. If a device determines that it needs to receive a notification update because the notification version in the primary message is higher than the current local notification version, then the device will tune to the notification flow channel to collect the number of notifications indicated in the number of notification field.
FIG. 2 provides an example of the formatting of a notification message in the notification flow, in accordance with the prior art. The notification message 60 includes a notification version block 70, a notification ID block 80, a composite address block 90 and a notification record block 100. The notification version block 70 indicates the version of the notification flow data that the message corresponds to. The notification ID block 80 uniquely identifies a notification message among notification messages of a particular notification version. The composite address block 90 additionally includes an address class sub-block 92 and an address sub-block 94 that indicate the set of devices to which the notification is relevant. For example, the address may be a service ID, a package ID or the like. The notification record block 100 further includes a notification type sub-block 102, a message compression type sub-block 104 and the notification detail sub-block 106, which provides the actual notification message.
A problem exists in the current notification process implemented in wireless broadcast systems, in that, devices are forced to receive all of the active notifications being broadcasted wherever there is a change/update of the notification version. By unnecessary acquiring all of the active notifications, as opposed to only those newer notifications that the device does not possess, the device must listen for longer periods of time to capture all of the messages and, thus battery power is inefficiently consumed.
FIGS. 3 and 4 provide an example of the current notification process as implemented in wireless broadcast systems, according to the prior art. FIG. 3 illustrates a first notification version designated in the primary flow message 110 in the notification version block 112 as version twenty (20). The primary flow message 110 also includes a number notification block 114 that indicates that ten (10) active notifications are associated with version twenty (20). Therefore, in the notification flow ten notification messages 60-0-60-9 are being broadcasted for version twenty (20), with the version being indicated in the notification version block 70 and the notification identifier, zero-nine (0-9), being indicated in the notification ID block 80.
FIG. 4 illustrates a second notification version designated in the primary flow message 110 in the notification version block 112 as version twenty-one (21). The primary flow message 110 also includes the number notification block 114 that indicates that eleven (11) active notifications are associated with version twenty-one (21), thus, in this example, one additional notification has been added to the notification flow. As such, the network device(s) responsible for generating and communicating the overhead messages, updates the primary flow message 110 to indicate in the notification version block 112, the updated version twenty-one (21) and the number notification block 114 is updated to reflect eleven notifications active in version twenty-one (21). Additionally, all of the messages 60-0-60-10 in the notification flow are updated, such that the notification version block 70 indicates version twenty-one (21) and the notification ID block 80 indicates the identifier individually associated with each of the eleven (11) notifications in version twenty-one (21).
From the broadcast-receiving device side, once the device detects, in the primary message, a change in notification version from version twenty (20) to version twenty-one (21), the device will tune to the notification flow and capture all eleven (11) notifications associated with version twenty-one (21). As previously noted, the device needs to capture all eleven (11) active notifications regardless of how many active notifications in version twenty-one (21) the device previously captured and stores with respect to previous versions. The need to capture all of the active notifications in the current version consumes unnecessary device power if the device already possesses notifications associated with a previous version. The battery power consumption problem becomes more evident in instances in which a large number of active notifications exist in the notification flow or if a high churn/turnover rate exists amongst the active notifications (e.g., notification versions are frequently changing due to frequent adding or removal of notifications).
Therefore, a need exists to develop a notification process in broadcast networks that serves to minimize notification acquisition time and, thus, minimize power consumption in devices that receive the broadcast service, in particular, wireless devices that operate on battery power limitations.